20장. 클라우드 AI 운영 설계

1. AI 기능은 만들고 나서부터가 더 중요하다

앞 장에서는 클라우드 AI 비용을 어떻게 이해하고 최적화할 수 있는지 살펴보았다.

AI 기능은 처음 만들 때보다 운영에 들어간 뒤 더 많은 문제가 드러난다.

개발 환경에서는 몇 번 테스트해보고 “잘 된다”고 느낄 수 있다.

개발자 테스트:
- 고객 문의 요약이 잘 됨
- 문서 검색 답변이 자연스러움
- 코드 리뷰 의견도 그럴듯함

하지만 운영 환경에서는 상황이 달라진다.

운영 환경:
- 사용자가 동시에 많이 요청한다.
- 입력 데이터 길이가 제각각이다.
- AI 응답이 느릴 때가 있다.
- 가끔 JSON 형식이 깨진다.
- 특정 모델 장애가 발생한다.
- 비용이 예상보다 빠르게 증가한다.
- 사용자 권한에 따라 볼 수 있는 문서가 다르다.
- AI 답변이 그럴듯하지만 틀릴 수 있다.

일반 API 기능은 보통 정해진 로직대로 동작한다.

입력
→ 검증
→ DB 조회
→ 정해진 응답 반환

반면 AI 기능은 모델이 응답을 생성한다.

입력
→ 프롬프트 구성
→ 모델 호출
→ 생성된 응답 반환

이 차이 때문에 AI 기능은 운영에서 더 많은 변수를 가진다.

- 같은 질문에도 모델 설정에 따라 답변이 달라질 수 있다.
- 입력이 길면 응답 시간이 길어진다.
- 모델 제공자의 장애에 영향을 받는다.
- 응답이 항상 원하는 형식으로 오지 않을 수 있다.
- 사용량에 따라 비용이 계속 변한다.
- 답변 품질을 숫자로 측정하기 어렵다.

따라서 클라우드 AI 운영 설계는 단순히 “API가 실패하면 재시도한다” 수준으로 끝나면 안 된다.

운영에서는 다음을 함께 설계해야 한다.

- 장애 대응
- 타임아웃
- 재시도
- fallback
- 로그와 모니터링
- 비용 감시
- 응답 품질 관리
- 민감 정보 보호
- 모델 변경 이력 관리

이 장에서는 클라우드 AI를 운영 서비스에 안정적으로 붙이기 위해 어떤 구조와 기준이 필요한지 살펴본다.

2. AI 장애는 일반 API 장애와 다르다

AI 기능도 외부 API를 호출한다는 점에서는 일반 API 연동과 비슷하다.

하지만 AI 장애는 일반 API 장애보다 더 다양하게 나타난다.

일반적인 외부 API 장애는 보통 다음처럼 드러난다.

- HTTP 500 오류
- timeout
- 인증 오류
- 요청 제한 초과
- 네트워크 오류

AI API도 이런 장애가 발생한다.

하지만 AI 기능에는 여기에 더해 다음 문제가 생길 수 있다.

- 응답은 왔지만 형식이 잘못됨
- JSON으로 달라고 했는데 설명 문장이 섞여 있음
- 답변이 너무 길거나 중간에 잘림
- 문서에 없는 내용을 지어냄
- 안전 정책 때문에 답변이 거절됨
- 모델 변경 후 답변 품질이 달라짐
- 특정 언어, 특정 도메인에서 품질이 떨어짐
- 응답 시간이 평소보다 크게 늘어남

즉, AI 장애는 “호출 실패”만 의미하지 않는다.

응답이 오더라도 서비스에서 사용할 수 없는 상태라면 장애로 봐야 한다.

예를 들어 고객 문의 분류 기능이 있다고 해보자.

서비스는 다음과 같은 JSON을 기대한다.

{
  "category": "payment",
  "priority": "high",
  "summary": "사용자가 하트 충전 후 반영되지 않는 문제를 문의함"
}

그런데 AI가 이렇게 응답할 수 있다.

이 문의는 결제 관련 문의로 보입니다.
중요도는 높습니다.
요약하면 하트 충전 후 반영되지 않는 문제입니다.

사람이 읽기에는 괜찮다. 하지만 서버가 JSON으로 파싱해야 한다면 실패다.

또는 이런 응답이 올 수도 있다.

{
  "category": "billing_issue",
  "priority": "urgent",
  "summary": "충전 미반영 문의"
}

JSON 형식은 맞지만 허용된 값이 아니다.

서비스가 허용한 category가 payment, login, refund, other라면 billing_issue는 처리할 수 없다.

따라서 AI 운영에서는 성공 기준을 명확히 해야 한다.

HTTP 200 응답을 받았다
= 성공

이렇게 보면 안 된다.

응답을 받았고,
형식이 맞고,
허용된 값이며,
정책상 노출 가능하고,
업무적으로 사용할 수 있어야 성공이다.

AI 기능의 운영 상태는 일반 API보다 더 넓게 봐야 한다.

3. 타임아웃은 반드시 설정해야 한다

AI API는 응답 시간이 길어질 수 있다.

짧은 분류 요청은 빠르게 끝날 수 있지만, 긴 문서 요약이나 RAG 답변은 오래 걸릴 수 있다.

타임아웃을 설정하지 않으면 요청이 너무 오래 대기할 수 있다.

사용자 요청
→ AI API 호출
→ 응답이 오지 않음
→ 백엔드 대기
→ 프론트엔드 대기
→ 사용자는 멈춘 것처럼 느낌

운영 서비스에서는 모든 외부 API 호출에 타임아웃이 필요하다.
AI API도 예외가 아니다.

예를 들어 기능별로 타임아웃을 다르게 둘 수 있다.

동기 요청에서 너무 긴 타임아웃을 두면 사용자 경험이 나빠진다.

예를 들어 사용자가 버튼을 눌렀는데 60초 동안 기다리게 만들면 대부분 실패한 것으로 느낀다.

이런 기능은 비동기로 전환하는 것이 좋다.

나쁜 구조:
긴 문서 요약 요청
→ HTTP 요청 유지
→ 60초 이상 대기
→ timeout 또는 사용자 이탈

좋은 구조:
긴 문서 요약 요청
→ 작업 ID 반환
→ 백그라운드 처리
→ 완료 후 결과 확인

타임아웃은 여러 단계에 있어야 한다.

프론트엔드:
사용자에게 로딩 상태와 취소 버튼 제공

백엔드:
AI API 호출 timeout 설정

Queue/Worker:
작업 전체 timeout 설정

인프라:
API Gateway, Load Balancer, Lambda timeout 확인

타임아웃을 설정할 때는 AI 모델의 평균 응답 시간과 최악의 응답 시간을 함께 봐야 한다.

평균 응답 시간:
2초

95퍼센타일 응답 시간:
8초

최대 응답 시간:
30초 이상 발생 가능

평균만 보면 안 된다. 운영에서는 느린 요청이 사용자 경험과 장애율에 영향을 준다.

퍼센타일은 전체 요청 중 특정 비율이 어느 시간 안에 끝났는지를 보는 지표다.
예를 들어 95퍼센타일 응답 시간이 8초라면, 95%의 요청은 8초 안에 끝나고 나머지 5%는 더 오래 걸린다는 뜻이다.

4. 재시도 정책은 제한적으로 설계해야 한다

외부 API가 실패하면 재시도를 고려할 수 있다.

AI API도 일시적인 네트워크 오류나 서버 오류라면 재시도가 도움이 될 수 있다.

하지만 AI API 재시도는 조심해야 한다.

첫 번째 이유는 비용이다.

재시도도 요청이다.
재시도할 때마다 토큰 비용이 발생할 수 있다.

원래 요청 1회
+ 재시도 2회
= 최대 3회 비용 발생 가능

두 번째 이유는 중복 처리다.

AI 응답이 늦게 도착했는데 클라이언트나 서버는 timeout으로 판단했을 수 있다.
이때 같은 작업을 다시 실행하면 결과가 중복 저장될 수 있다.

세 번째 이유는 요청 제한이다.

이미 AI 제공자 쪽에서 요청 제한에 걸렸는데 계속 재시도하면 상황이 더 나빠질 수 있다.

재시도는 에러 유형에 따라 다르게 해야 한다.

재시도를 할 때는 간격을 점점 늘리는 방식이 좋다.

1차 실패
→ 1초 후 재시도

2차 실패
→ 3초 후 재시도

3차 실패
→ 최종 실패 처리

이런 방식을 exponential backoff라고 한다.

하지만 무조건 여러 번 재시도하는 것이 좋은 것은 아니다.

AI 기능에서는 다음 원칙이 안전하다.

- 재시도 가능한 오류만 재시도한다.
- 최대 재시도 횟수를 제한한다.
- 전체 처리 시간을 제한한다.
- 같은 작업이 중복 저장되지 않도록 작업 ID를 둔다.
- 요청 제한 초과 상태에서는 재시도를 멈춘다.
- 재시도 실패 후 사용자에게 명확한 안내를 제공한다.

예를 들어 고객 문의 요약 기능이라면 실패 시 재시도 버튼을 제공하는 정도로 충분할 수 있다.

AI 요약을 생성하지 못했습니다.
잠시 후 다시 시도해주세요.

반면 결제, 환불, 계정 정지 같은 중요한 작업은 AI 재시도와 자동 실행을 더 엄격하게 제한해야 한다.

5. fallback 구조를 준비해야 한다

fallback은 기본 처리 방식이 실패했을 때 사용할 대체 경로를 말한다.

AI 기능에서도 fallback은 중요하다.

클라우드 AI 모델이 항상 정상 동작한다고 가정하면 안 된다.

- 모델 장애
- 특정 리전 장애
- 요청 제한 초과
- 응답 지연
- 품질 문제
- 비용 제한 도달

이런 상황에서 AI 기능이 완전히 멈추면 사용자 경험이 나빠진다.

fallback 방식은 기능에 따라 달라진다.

1) AI 없이 기존 방식으로 처리

가장 안전한 fallback은 AI 기능이 실패해도 기존 업무가 계속되는 구조다.

예를 들어 고객 문의 요약 기능은 실패해도 상담원이 원문을 보면 된다.

AI 요약 성공:
요약 표시

AI 요약 실패:
요약 없이 원문 표시

이런 기능은 AI 실패가 서비스 장애로 이어지지 않는다.

초기 AI 기능은 이런 구조가 좋다.

2) 대체 모델 사용

특정 모델이 실패하면 다른 모델을 사용할 수 있다.

1차 모델:
고성능 모델

실패 시:
저비용 또는 대체 모델

그래도 실패 시:
사용자에게 실패 안내

대체 모델을 사용할 때는 응답 품질 차이를 고려해야 한다.

예를 들어 고성능 모델이 장애 분석을 잘하더라도, 대체 모델은 품질이 낮을 수 있다.

따라서 대체 모델로 생성한 답변에는 표시를 다르게 할 수 있다.

기본 모델 응답:
정상 분석 결과

대체 모델 응답:
간략 분석 결과

3) 캐시된 결과 사용

같은 질문이나 같은 문서에 대한 결과가 캐시에 있다면, 새로 AI를 호출하지 않고 기존 결과를 보여줄 수 있다.

AI API 장애
→ 최근 캐시 결과 확인
→ 캐시가 있으면 표시
→ 없으면 실패 안내

다만 캐시가 오래되었거나 권한이 맞지 않으면 사용하면 안 된다.

4) 비동기 처리로 전환

동기 응답이 실패하거나 오래 걸릴 것 같다면 비동기 작업으로 전환할 수 있다.

즉시 처리 어려움
→ 작업으로 등록
→ 완료 후 알림

예를 들어 긴 문서 분석은 처음부터 비동기 구조가 더 적합하다.

fallback을 설계할 때 중요한 것은 AI 기능의 중요도다.

AI 기능은 실패할 수 있다.
좋은 운영 설계는 실패하지 않는 구조가 아니라, 실패해도 서비스 전체가 무너지지 않는 구조다.

6. 로그는 문제 해결의 출발점이다

AI 기능을 운영하려면 로그가 필요하다.

문제가 발생했을 때 로그가 없으면 원인을 찾기 어렵다.

예를 들어 사용자가 이렇게 말할 수 있다.

AI 답변이 이상해요.

이때 확인해야 할 것이 많다.

- 어떤 기능에서 발생했는가?
- 어떤 모델을 사용했는가?
- 입력 길이는 어느 정도였는가?
- 어떤 프롬프트 버전이 사용되었는가?
- 검색된 문서는 무엇이었는가?
- 응답 시간은 얼마나 걸렸는가?
- 응답 형식 검증은 통과했는가?
- 사용자 권한 필터가 적용되었는가?

AI 기능의 로그에는 다음 정보가 필요하다.

예시는 다음과 같다.

{
  "requestId": "ai_req_20260505_001",
  "userId": "admin_123",
  "feature": "inquiry_summary",
  "model": "summary-model-v2",
  "promptVersion": "inquiry-summary-2026-05-01",
  "inputTokens": 1420,
  "outputTokens": 210,
  "latencyMs": 2800,
  "status": "success",
  "retryCount": 0,
  "fallbackUsed": false,
  "createdAt": "2026-05-05T10:15:00+09:00"
}

이 로그가 있으면 다음을 분석할 수 있다.

- 특정 모델에서 실패율이 높아졌는가?
- 특정 프롬프트 버전 이후 응답 시간이 늘었는가?
- 입력 토큰이 갑자기 커졌는가?
- fallback이 자주 발생하는가?
- 특정 기능이 비용을 많이 쓰는가?

하지만 로그에 원문을 그대로 남기는 것은 위험하다.

AI 요청에는 고객 문의, 내부 문서, 운영 로그, 코드, 개인정보가 포함될 수 있다.

따라서 로그는 기본적으로 메타데이터 중심으로 남기는 것이 좋다.

권장:
요청 ID, 기능명, 모델명, 토큰 수, 응답 시간, 상태

주의:
사용자 입력 원문, AI 응답 전체, 내부 문서 원문, 개인정보

원문이 꼭 필요한 디버깅 상황이라면 별도 정책을 둬야 한다.

- 마스킹 후 저장
- 짧은 보관 기간
- 접근 권한 제한
- 조회 로그 기록
- 다운로드 제한

AI 로그는 운영에 반드시 필요하지만, 로그 자체가 보안 위험이 되지 않도록 설계해야 한다.

7. 모니터링은 기술 지표와 품질 지표를 함께 봐야 한다

일반 API 모니터링에서는 주로 기술 지표를 본다.

- 요청 수
- 응답 시간
- 에러율
- CPU 사용량
- 메모리 사용량

AI 기능도 이런 지표가 필요하다.

하지만 이것만으로는 부족하다.

AI 기능은 응답이 성공해도 품질이 나쁠 수 있기 때문이다.

예를 들어 HTTP 200으로 응답했지만, AI 답변이 문서와 맞지 않을 수 있다.
또 JSON 형식은 맞지만 분류가 틀릴 수도 있다.

그래서 AI 모니터링은 두 가지로 나눠야 한다.

1. 기술 지표
2. 품질 지표

기술 지표는 시스템이 정상 동작하는지 확인한다.

품질 지표는 AI 답변이 실제로 쓸 만한지 확인한다.

예를 들어 고객 문의 요약 기능에서는 다음을 볼 수 있다.

기술 지표:
요청 수, 응답 시간, 실패율, 토큰 사용량

품질 지표:
상담원이 요약을 수정한 비율
요약을 사용하지 않고 폐기한 비율
요약 만족도

문서 검색 챗봇에서는 다음이 중요하다.

기술 지표:
응답 시간, 검색 시간, LLM 호출 시간

품질 지표:
출처 표시 여부
문서에 없는 답변 비율
사용자 피드백
검색 결과 관련성

AI 운영에서는 “서버가 정상인지”와 “답변이 쓸 만한지”를 함께 봐야 한다.

8. 비용 모니터링은 운영 지표의 일부다

AI 비용은 운영 지표로 다뤄야 한다.

일반 기능은 서버 비용이 트래픽에 따라 늘어나긴 하지만, AI API는 요청 단위 비용이 더 직접적으로 발생한다.

따라서 비용을 월말 청구서로만 확인하면 늦다.

운영 중에 다음 지표를 봐야 한다.

- 일별 요청 수
- 기능별 토큰 사용량
- 모델별 비용
- 사용자별 사용량
- 평균 입력 토큰
- 평균 출력 토큰
- 예상 월 비용
- 예산 대비 사용률

비용 알림 기준도 필요하다.

월 예산 50% 도달:
관찰

월 예산 80% 도달:
담당자 알림

월 예산 100% 도달:
고비용 기능 제한 또는 승인 필요

비정상 급증:
즉시 알림

예를 들어 문서 검색 챗봇 비용이 갑자기 늘었다면 다음을 확인해야 한다.

- 사용자가 늘었는가?
- 검색 chunk 수가 늘었는가?
- 대화 이력이 너무 길어졌는가?
- 특정 모델 단가가 높은가?
- 재시도가 반복되고 있는가?
- 봇이나 자동화가 비정상 호출하고 있는가?

비용 모니터링은 단순히 비용 절감 목적만이 아니다.

비용 급증은 장애의 신호일 수도 있다.

- 무한 재시도
- 자동화 루프
- 프롬프트 버그
- 문서 검색 범위 오류
- 사용량 제한 미적용

따라서 AI 운영 대시보드에는 기술 지표, 품질 지표, 비용 지표가 함께 있어야 한다.

9. 민감 정보 마스킹은 운영의 기본이다

클라우드 AI는 외부 모델 API를 호출하는 구조가 많다.

따라서 어떤 데이터가 AI에게 전달되는지 관리해야 한다.

AI 입력에는 다음과 같은 민감 정보가 포함될 수 있다.

- 이름
- 이메일
- 전화번호
- IP 주소
- 결제 정보
- 계정 정보
- 인증 토큰
- 내부 URL
- 운영 로그
- 소스 코드
- 고객 상담 내용

AI에게 꼭 필요하지 않은 민감 정보는 보내지 않는 것이 좋다.

예를 들어 고객 문의 요약 기능에서는 전화번호가 필요하지 않을 수 있다.

원문:
홍길동입니다. 010-1234-5678로 연락 주세요.
하트를 충전했는데 반영이 안 됩니다.

마스킹 후:
[이름]입니다. [전화번호]로 연락 주세요.
하트를 충전했는데 반영이 안 됩니다.

요약 결과에는 문제 상황만 있으면 충분하다.

사용자가 하트를 충전했지만 서비스에 반영되지 않았다고 문의함.

마스킹은 AI 호출 전과 로그 저장 전에 모두 고려해야 한다.

AI 호출 전:
외부 모델에 보내기 전에 민감 정보 제거

로그 저장 전:
운영 로그에 원문이 남지 않도록 마스킹

단, 마스킹에도 주의할 점이 있다.

너무 많이 제거하면 AI가 문제를 이해하지 못할 수 있다.

예를 들어 장애 로그 분석에서 모든 URL, 서버명, 에러 코드를 제거하면 원인 분석이 어려워질 수 있다.

따라서 민감 정보와 분석에 필요한 정보를 구분해야 한다.

제거 또는 치환:
전화번호, 이메일, 인증 토큰, 세션 ID

유지 가능:
에러 코드, HTTP status, 서비스명, 시간 정보

상황에 따라 치환:
서버 IP, 내부 도메인, 사용자 ID

마스킹 정책은 기능별로 달라야 한다.

마스킹은 보안팀만의 일이 아니다.
AI 기능을 설계하는 개발자가 입력 데이터의 성격을 이해하고 함께 설계해야 한다.

10. 응답 검증 로직이 필요하다

AI 응답은 항상 기대한 형태로 오지 않는다.

특히 서비스 로직에서 AI 응답을 데이터로 사용하는 경우에는 검증이 필수다.

예를 들어 고객 문의 분류 기능은 다음 JSON을 기대한다고 해보자.

{
  "category": "payment",
  "priority": "high",
  "summary": "하트 충전 후 미반영 문의"
}

서버는 응답을 받은 뒤 다음을 검증해야 한다.

- JSON 파싱이 가능한가?
- 필수 필드가 있는가?
- category 값이 허용된 목록 안에 있는가?
- priority 값이 허용된 목록 안에 있는가?
- summary가 너무 길지 않은가?
- 개인정보가 포함되어 있지 않은가?

검증에 실패하면 선택지가 있다.

1. AI에게 수정 요청을 1회 보낸다.
2. 기본값으로 처리한다.
3. 수동 검토 대상으로 보낸다.
4. 사용자에게 실패 메시지를 보여준다.

예를 들어 JSON 파싱에 실패했다면, AI에게 다음처럼 재요청할 수 있다.

이전 응답은 JSON 형식이 아닙니다.
설명 문장을 제외하고 아래 JSON 형식으로만 다시 작성하세요.

{
  "category": "payment | login | refund | other",
  "priority": "low | medium | high",
  "summary": "string"
}

하지만 이 재요청도 무제한 하면 안 된다.
비용과 지연시간이 늘어나기 때문이다.

보통 1회 정도만 재시도하고, 그래도 실패하면 fallback 처리하는 것이 좋다.

구조화된 응답은 스키마 검증을 사용하는 것이 좋다.

type InquiryClassification = {
    category: "payment" | "login" | "refund" | "other";
    priority: "low" | "medium" | "high";
    summary: string;
};

function validateResult(data: unknown): InquiryClassification {
    // 실제 코드에서는 zod, joi, class-validator 같은 도구를 사용할 수 있다.
    // 여기서는 개념 설명용으로 단순화했다.
    if (!data || typeof data !== "object") {
        throw new Error("Invalid response");
    }

    return data as InquiryClassification;
}

AI 응답 검증은 운영 안정성의 핵심이다.

응답이 그럴듯하다고 해서 바로 DB에 저장하거나 후속 작업을 실행하면 안 된다.

11. 모델 변경 이력을 관리해야 한다

AI 모델은 계속 바뀐다.

클라우드 제공자는 새 모델을 출시하고, 기존 모델을 개선하거나, 특정 모델을 더 이상 사용하지 않게 할 수 있다.

개발팀도 비용이나 품질 문제로 모델을 바꾸고 싶을 수 있다.

예를 들어 다음과 같은 변경이 생길 수 있다.

- 요약 기능 모델을 저비용 모델로 변경
- 코드 리뷰 기능 모델을 고성능 모델로 변경
- RAG 답변 모델을 긴 컨텍스트 모델로 변경
- 장애 대응을 위해 fallback 모델 추가
- 특정 모델 응답 품질 저하로 이전 모델로 되돌림

이때 모델 변경 이력을 남기지 않으면 문제가 생긴다.

사용자가 이렇게 말할 수 있다.

지난주부터 AI 답변이 이상해졌어요.

이때 확인해야 한다.

- 모델을 바꿨는가?
- 프롬프트를 바꿨는가?
- 검색 설정을 바꿨는가?
- temperature를 바꿨는가?
- 출력 길이 제한을 바꿨는가?

모델 변경 이력은 최소한 다음 정보를 포함해야 한다.

예를 들어 다음처럼 기록할 수 있다.

변경 일시:
2026-05-05 14:00

기능:
고객 문의 요약

이전 모델:
summary-model-v1

변경 모델:
summary-model-v2

변경 이유:
응답 속도 개선 및 비용 절감

검증 결과:
샘플 100건 기준 상담원 수정률 변화 없음

rollback:
환경 변수 MODEL_INQUIRY_SUMMARY를 v1으로 변경

모델 변경은 코드 변경만큼 중요하다.

AI 기능에서는 모델, 프롬프트, 검색 설정이 모두 서비스 로직의 일부다.

따라서 변경 이력을 남기고, 가능하면 배포와 동일한 절차로 관리하는 것이 좋다.

12. 프롬프트 변경 이력도 관리해야 한다

AI 기능에서 프롬프트는 사실상 로직이다.

일반 코드의 if, else, SQL 쿼리처럼 프롬프트도 결과를 바꾼다.

예를 들어 다음 문장 하나가 답변 성격을 크게 바꿀 수 있다.

확실하지 않은 내용은 추정이라고 표시해라.

또는 다음 문장이 없으면 AI가 문서에 없는 내용을 만들어낼 수 있다.

참고 문서에 없는 내용은 답하지 말고 모른다고 말해라.

프롬프트를 코드 안에 흩어놓으면 관리가 어렵다.

customerController.ts 안의 문자열
adminReportService.ts 안의 문자열
batchWorker.ts 안의 문자열

프롬프트는 가능하면 별도 템플릿으로 관리하는 것이 좋다.

prompts/
  inquiry-summary-v1.md
  inquiry-summary-v2.md
  incident-analysis-v1.md
  rag-answer-v3.md

프롬프트 변경 이력에는 다음 정보를 남기면 좋다.

예를 들어 RAG 답변 프롬프트를 바꿨다고 해보자.

변경 전:
아래 문서를 참고해서 답변해라.

변경 후:
아래 문서에 있는 내용만 근거로 답변해라.
문서에 없는 내용은 "제공된 문서에서는 확인할 수 없습니다"라고 답해라.
답변 마지막에 사용한 문서 제목을 표시해라.

이 변경은 환각을 줄이고 출처 표시를 강화할 수 있다.

하지만 답변이 너무 보수적으로 바뀔 수도 있다.

따라서 프롬프트 변경 후에는 품질 평가가 필요하다.

프롬프트는 운영 중 계속 개선된다.
그러므로 처음부터 버전 관리 대상으로 보는 것이 좋다.

13. AI 품질 저하를 감지하는 방법

AI 품질은 일반적인 API 성공률처럼 단순하지 않다.

서버는 정상 응답을 받았지만, 사용자는 답변이 별로라고 느낄 수 있다.

예를 들어 다음 상황이 있다.

- 요약이 핵심을 빠뜨린다.
- 문서 검색 답변이 출처와 맞지 않는다.
- 코드 리뷰가 쓸데없는 코멘트를 많이 남긴다.
- 장애 분석이 근거 없이 원인을 단정한다.
- 고객 답변 초안이 너무 딱딱하거나 부정확하다.

이런 품질 저하는 자동으로 감지하기 어렵다.

그래서 여러 신호를 함께 봐야 한다.

- 사용자 피드백
- AI 초안 수정률
- 답변 재생성 횟수
- 응답 폐기율
- RAG 출처 클릭률
- 신고된 답변 수
- 샘플 평가 점수

예를 들어 고객 문의 요약 기능에서는 상담원이 AI 요약을 얼마나 수정하는지 볼 수 있다.

AI 요약 생성
→ 상담원이 수정
→ 수정 전후 차이 기록

수정률이 갑자기 높아졌다면 품질 문제가 있을 수 있다.

문서 검색 챗봇에서는 사용자가 답변 출처를 클릭했는지, 답변에 만족했는지 피드백을 받을 수 있다.

이 답변이 도움이 되었나요?
[도움됨] [도움 안 됨]

도움 안 됨이 많아지면 검색 품질이나 답변 품질을 점검해야 한다.

코드 리뷰 AI에서는 개발자가 AI 코멘트를 실제로 반영했는지 볼 수 있다.

AI 리뷰 코멘트 수:
100개

개발자가 반영한 코멘트:
15개

불필요하다고 닫은 코멘트:
70개

불필요한 코멘트가 너무 많으면 프롬프트나 리뷰 기준을 조정해야 한다.

AI 품질 평가는 뒤에서 별도 장에서 더 자세히 다루겠지만, 운영 단계에서도 최소한의 품질 지표는 반드시 필요하다.

14. RAG 운영에서는 검색 실패도 장애다

RAG 기반 AI에서는 LLM 호출만 모니터링하면 부족하다.

RAG는 검색과 생성이 함께 동작한다.

사용자 질문
→ 문서 검색
→ 검색 결과를 기반으로 답변 생성

따라서 답변 품질이 나쁘다면 원인이 두 가지 중 하나일 수 있다.

1. 검색이 잘못되었다.
2. 모델이 검색 결과를 잘못 사용했다.

예를 들어 사용자가 이렇게 질문했다.

하트 충전 후 반영이 안 될 때 처리 절차 알려줘.

검색 결과가 다음과 같다면 문제가 있다.

검색 결과:
- 로그인 비밀번호 변경 가이드
- 닉네임 변경 정책
- 방송 송출 가이드

이 경우 LLM이 아무리 좋아도 답변이 정확하기 어렵다.

반대로 검색 결과는 맞는데 모델이 문서에 없는 내용을 덧붙일 수도 있다.

검색 결과:
- 충전 미반영 처리 절차
- 결제 승인 확인 가이드

AI 답변:
3일 이내 자동 환불됩니다.

문서에 자동 환불 내용이 없다면 환각이다.

RAG 운영에서는 다음 지표를 봐야 한다.

RAG에서 검색 실패는 단순 품질 문제가 아니라 운영 장애로 봐야 한다.

문서 검색 챗봇이 관련 문서를 찾지 못한다면 사용자는 AI를 신뢰하지 않게 된다.

따라서 RAG 운영에서는 LLM 응답뿐 아니라 검색 단계의 로그도 남겨야 한다.

{
  "requestId": "rag_req_001",
  "query": "하트 충전 미반영 처리 절차",
  "retrievedChunks": 5,
  "topScore": 0.82,
  "documentIds": [
    "doc_payment_001",
    "doc_cs_004"
  ],
  "permissionFiltered": true,
  "answerGenerated": true
}

물론 실제 운영 로그에는 원문 질문을 그대로 저장하지 않거나, 마스킹 정책을 적용해야 한다.

15. 운영 중 모델 장애에 대비하는 구조

클라우드 AI는 외부 서비스다.

따라서 모델 장애에 대비해야 한다.

모델 장애는 다음처럼 나타날 수 있다.

- 특정 모델 호출 실패
- 응답 시간이 급격히 증가
- 요청 제한 초과
- 특정 리전 장애
- 모델 업데이트 후 품질 저하

대비 방법은 여러 가지가 있다.

1) 모델 fallback

특정 모델이 실패하면 대체 모델을 사용한다.

primary model
→ 실패
→ fallback model
→ 응답

단, 대체 모델의 품질 차이를 고려해야 한다.

2) 기능별 degrade

AI 기능을 완전히 중단하지 않고 기능을 축소한다.

정상 상태:
문서 검색 + AI 답변 생성

장애 상태:
문서 검색 결과만 표시하고 AI 답변 생성은 비활성화

3) 수동 처리 전환

관리자 보조 기능이라면 AI 실패 시 사람이 기존 방식으로 처리할 수 있다.

AI 요약 실패
→ 원문 표시
→ 상담원이 직접 요약

4) 장애 공지

사용자에게 명확한 안내를 제공한다.

현재 AI 답변 생성이 지연되고 있습니다.
잠시 후 다시 시도해주세요.
기존 문서 검색은 계속 사용할 수 있습니다.

모델 장애 대응에서 중요한 것은 AI 기능의 중요도를 분류하는 것이다.

AI 기능은 가능하면 핵심 기능의 유일한 경로가 되지 않게 설계하는 것이 좋다.

16. 승인 단계가 필요한 기능을 구분해야 한다

AI 운영에서 중요한 기준 중 하나는 “AI가 만든 결과가 실제 행동으로 이어지는가”다.

단순히 답변을 보여주는 기능과, 시스템 작업을 실행하는 기능은 위험도가 다르다.

예를 들어 다음은 비교적 위험도가 낮다.

- 고객 문의 요약 초안 생성
- 회의록 요약
- 운영 보고서 초안 작성
- 코드 설명

반면 다음은 위험도가 높다.

- 고객에게 답변 자동 발송
- 계정 정지 자동 실행
- 환불 승인 자동 처리
- DB 데이터 수정
- Jira 이슈 상태 변경
- 배포 작업 실행

AI가 후자의 작업을 직접 실행하게 하면 위험하다.

이런 기능에는 사람 승인 단계가 필요하다.

AI 제안
→ 사람이 검토
→ 승인
→ 시스템 실행
→ 실행 로그 저장

예를 들어 Jira 이슈 생성 자동화를 생각해보자.

AI:
장애 로그를 분석한 결과, 재발 방지를 위해 다음 Jira 이슈를 생성하는 것이 좋습니다.

제안:
- 제목: 결제 콜백 timeout 모니터링 강화
- 담당팀: 플랫폼개발1팀
- 우선순위: High

사용자:
[승인 후 생성] 버튼 클릭

AI는 제안만 하고, 실제 생성은 사람이 승인한 뒤 실행한다.

승인 단계가 필요한 기준은 다음과 같다.

AI 에이전트와 MCP를 다룰 때도 이 원칙은 매우 중요하다.
AI가 도구를 사용할 수 있게 되면 반드시 읽기 작업과 쓰기 작업을 분리하고, 위험한 작업에는 승인 단계를 둬야 한다.

17. 운영 환경 배포 전 테스트 기준

AI 기능을 운영 환경에 배포하기 전에 테스트 기준을 정해야 한다.

일반 기능은 입력과 출력이 비교적 명확하다.

입력 A
→ 출력 B

AI 기능은 항상 같은 답변을 보장하기 어렵다.

그래서 테스트 기준도 조금 다르게 잡아야 한다.

AI 기능 배포 전에는 다음을 확인해야 한다.

- 정상 입력에서 기대한 형식으로 응답하는가
- 빈 입력이나 너무 긴 입력을 처리하는가
- 민감 정보가 포함된 입력을 마스킹하는가
- JSON 응답 스키마를 지키는가
- 문서에 없는 질문에 모른다고 답하는가
- 권한 없는 문서를 사용하지 않는가
- timeout과 실패 처리가 동작하는가
- 비용 제한이 적용되는가
- 로그에 원문이 남지 않는가
- fallback이 동작하는가

RAG 기능이라면 추가 테스트가 필요하다.

- 관련 문서를 잘 검색하는가
- 오래된 문서보다 최신 문서를 우선하는가
- 권한 필터가 적용되는가
- 출처를 표시하는가
- 문서에 없는 내용은 답하지 않는가

테스트 데이터셋을 만들어두면 좋다.

예를 들어 고객 문의 요약 기능이라면 샘플 100건을 준비한다.

- 결제 문의
- 로그인 문의
- 환불 문의
- 방송 문의
- 악성 입력
- 개인정보 포함 입력
- 매우 긴 입력
- 빈 입력

각 샘플에 대해 기대하는 기준을 정한다.

- 3문장 이내인가
- 개인정보를 포함하지 않는가
- 문의 유형이 맞는가
- 추정하지 않는가

AI 테스트는 완전한 정답 비교가 어려울 수 있다.
그래도 최소 기준을 정하면 운영 배포 위험을 줄일 수 있다.

18. 클라우드 AI 운영 체크리스트

클라우드 AI 기능을 운영할 때는 다음 항목을 점검하면 좋다.

이 체크리스트는 한 번만 확인하는 것이 아니다.

AI 기능은 모델, 프롬프트, 데이터, 사용량에 따라 계속 변한다.

따라서 운영 중에도 주기적으로 점검해야 한다.

신규 기능 출시 전:
보안, 비용, 품질 기준 확인

운영 중:
지표 모니터링, 사용자 피드백 확인

모델 변경 전:
샘플 평가, 비용 비교

장애 발생 후:
로그 분석, fallback 동작 확인

정기 점검:
프롬프트, 문서, 권한, 비용 재검토

AI 운영은 한 번 구축하고 끝나는 일이 아니다.
계속 관찰하고 조정하는 과정이다.

19. 정리

클라우드 AI 기능은 개발보다 운영이 더 중요할 수 있다.

AI API 호출이 성공했다고 해서 서비스 기능이 성공한 것은 아니다.
응답 형식이 맞아야 하고, 사용자가 볼 수 있는 데이터만 사용해야 하며, 비용과 응답 시간도 관리되어야 한다.

AI 장애는 일반 API 장애보다 다양하다.

- 호출 실패
- timeout
- 요청 제한 초과
- 응답 형식 오류
- 품질 저하
- 환각
- 모델 장애
- 비용 급증

따라서 운영 설계에는 타임아웃, 재시도, fallback, 로그, 모니터링, 비용 감시, 응답 검증, 민감 정보 마스킹이 포함되어야 한다.

또한 모델과 프롬프트는 서비스 로직의 일부로 봐야 한다.
모델 변경 이력과 프롬프트 변경 이력을 관리해야 문제 발생 시 원인을 찾고 되돌릴 수 있다.

RAG 기반 AI에서는 LLM 호출뿐 아니라 검색 품질도 운영 대상이다.
관련 문서를 못 찾거나, 권한 없는 문서를 검색하거나, 출처 없이 답변하는 것도 운영 문제로 봐야 한다.

AI가 실제 시스템 작업을 수행하는 기능이라면 승인 단계가 필요하다.
AI는 제안하고, 사람은 검토하고, 시스템은 승인된 작업만 실행하는 구조가 안전하다.

이 장에서 기억해야 할 핵심은 하나다.

클라우드 AI 운영 설계는 “AI API가 실패하지 않게 하는 것”이 아니라,
실패해도 안전하고, 비용이 통제되고, 답변 품질을 추적할 수 있게 만드는 일이다.

20장 핵심 요약